Internet Surfer 2.0/Internet Surfer 2.0 (Wayzata Technology) (1996).iso/pc/text/mac/faqs.005

Text File | 1996-02-12 | 28KB | 698 lines

Frequently Asked Questions (FAQS);faqs.005



2) <a specific hostname>

Your directory can be mounted by anyone permitted to run the mount
command at hostname.  This might not be a trustworthy person; for
instance, if the machine is a PC running NFS, it could be anyone.

3) <a netgroup name>

If the netgroup:

a) is empty, anyone can mount your directory, from anywhere.

b) contains "(,,)", anyone can mount your directory, from anywhere.

c) contains the name of a netgroup which is empty or contains "(,,)",
   anyone can mount your directory, from anywhere.

d) contains "(hostname,,)", anyone on the named host who is permissioned
   to mount files can mount your directory.

e) contains "(,username,)", the named user can mount your directory,
   from anywhere.

4) <a word which is neither a hostname or a netgroup>

If you meant to export the directory to the host "athena" but actually
type "ahtena", the word "ahtena" is taken as a netgroup name, is found
to be an empty netgroup, and thus the directory can be mounted by
anyone, anywhere.

So, if you aren't careful about what you put into /etc/exports and
/etc/netgroup you could find that a user with a PC could

  a) mount your mainframe filestore as a network disk
  b) edit your /etc/passwd or .rhosts or /etc/hosts.equiv ...
  c) log into your mainframe as another user, possibly "root"

Disclaimer: The above information may not be true for all platforms
which provide an NFS serving capability, but is true for all of the ones
in my experience (AEM).  It should be noted that the SAFE way to create
an "empty" netgroup entry is:

               ngname (-,-,-)

Which is a netgroup which matches no-one on no-host on no-NIS-domain.

[ I am STILL working on PC NFS packages / ethics at the moment - AEM ]

Q.16 How can I generate safe passwords?

You can't.  The key word here is GENERATE.  Once an algorithm for
creating passwords is specified using upon some systematic method, it
merely becomes a matter of analysing your algorithm in order to find
every password on your system.

Unless the algorithm is very subtle, it will probably suffer from a very
low period (ie: it will soon start to repeat itself) so that either:

  a) a cracker can try out every possible output of the password
  generator on every user of the system, or

  b) the cracker can analyse the output of the password program,
  determine the algorithm being used, and apply the algorithm to other
  users to determine their passwords.

A beautiful example of this (where it was disastrously assumed that a
random number generator could generate an infinite number of random
passwords) is detailed in [Morris & Thompson].

The only way to get a reasonable amount of variety in your passwords
(I'm afraid) is to make them up.  Work out some flexible method of your
own which is NOT based upon:

  1) modifying any part of your name or name+initials
  2) modifying a dictionary word
  3) acronyms
  4) any systematic, well-adhered-to algorithm whatsoever

For instance, NEVER use passwords like:

alec7         - it's based on the users name (& it's too short anyway)
tteffum        - based on the users name again
gillian        - girlfiends name (in a dictionary)
naillig        - ditto, backwards
PORSCHE911     - it's in a dictionary
12345678     - it's in a dictionary (& people can watch you type it easily)
qwertyui     - ...ditto...
abcxyz        - ...ditto...
0ooooooo    - ...ditto...
Computer     - just because it's capitalised doesn't make it safe
wombat6     - ditto for appending some random character
6wombat     - ditto for prepending some random character
merde3        - even for french words...
mr.spock     - it's in a sci-fi dictionary
zeolite     - it's in a geological dictionary
ze0lite     - corrupted version of a word in a geological dictionary
ze0l1te     - ...ditto...
Z30L1T3     - ...ditto...

I hope that these examples emphasise that ANY password derived from ANY
dictionary word (or personal information), modified in ANY way,
constitutes a potentially guessable password.

For more detailed information in the same vein, you should read the
APPENDIX files which accompany Crack [Muffett].

Q.17 Why are passwords so important?

Because they are the first line of defence against interactive attacks
on your system.  It can be stated simply: if a cracker cannot interact
with your system(s), and he has no access to read or write the
information contained in the password file, then he has almost no
avenues of attack left open to break your system.

This is also why, if a cracker can at least read your password file (and
if you are on a vanilla modern Unix, you should assume this) it is so
important that he is not able to break any of the passwords contained
therein.  If he can, then it is also fair to assume that he can (a) log
on to your system and can then (b) break into "root" via an operating
system hole.

Q.18 How many possible passwords are there?

Most people ask this at one time or another, worried that programs like
Crack will eventually grow in power until they can do a completely
exhaustive search of all possible passwords, to break into a specific
users' account - usually root.

If (to simplify the maths) we make the assumptions that:

  1) Valid passwords are created from a set of 62 chars [A-Za-z0-9]
  2) Valid passwords are to be between 5 and 8 chars long

Then the size of the set of all valid passwords is: (in base 62)

                   100000 +
                  1000000 +
                 10000000 +
                100000000 =
                ---------
                111100000    (base 62)

A figure which is far too large to usefully undertake an exhaustive
search with current technologies.  Don't forget, however, that passwords
CAN be made up with even more characters then this; you can use <space>,
all the punctuation characters, and symbols (~<>|\#$%^&*) too.  If you
can use some of all the 95 non-control characters in passwords, this
increases the search space for a cracker to cover even further.

However, it's still MUCH more efficient for a cracker to get a copy of
"Crack", break into ANY account on the system (you only need one), log
onto the machine, and spoof his way up to root priviledges via operating
systems holes.

Take comfort from these figures.  If you can slam the door in the face
of a potential crackers with a robust password file, you have sealed
most of the major avenues of attack immediately.

Q.19 Where can I get more information?

Books:

[Kochan & Wood]
Unix System Security

A little dated for modern matters, but still a very good book on the
basics of Unix security.

[Spafford & Garfinkel]
Practical Unix Security

This wonderful book is a worthy successor to the above, and covers a
wide variety of the topics which the Unix (and some non Unix) system
manager of the 90's will come across.

>From: Gene Spafford <[e-mail]>
>Mention appendix E in "Practical Unix Security."

Okay: Appendix E contains an extensive bibliography with even more
pointers to security books than this FAQ contains.

[Stoll]
The Cuckoo's Egg

A real life 1980's thriller detailing the tracing of a cracker from
Berkeley across the USA and over the Atlantic to Germany.  An excellent
view from all points: a good read, informative about security, funny,
and a good illustration of the cracker psyche.  Contains an excellent
recipie for chocolate chip cookies.

A videotape of the "NOVA" (PBS's Science Program on TV) episode that
explained/reenacted this story is available from PBS Home Video.  They
have a toll-free 800 number within North America.

I believe that this program was aired on the BBC's "HORIZON" program,
and thus will be available from BBC Enterprises, but I haven't checked
this out yet - AEM

[Raymond] (Ed.)
The New Hackers Dictionary/Online Jargon File

A mish-mash of history and dictionary definitions which explains why it
is so wonderful to be a hacker, and why those crackers who aren't
hackers want to be called "hackers".  The Jargon File version is
available online - check an archie database for retails.  Latest
revision: 2.99.

[Gasser]
Building a Secure Computer System.

By Morrie Gasser, and van Nostrand Reinhold; explains what is required
to build a secure computer system.

[Rainbow Series] (Especially the "Orange Book")

>From: [e-mail] (Jeremy Epstein)
>The "Rainbow Series" consists of about 25 volumes.  Some of the
>more interesting ones are:
>
>    The "Orange Book", or Trusted Computer Systems Evaluation
>        Criteria, which describes functional and assurance
>        requirements for computer systems
>
>    Trusted Database Interpretation, which talks both about
>        trusted databases and building systems out of trusted
>        components
>
>    Trusted Network Interpretation, which (obviously) talks
>        about networked systems
>
>A (possibly) complete list is:
>    -- Department of Defense Trusted Computer System Evaluation Criteria
>       (TCSEC), aka the "Orange Book"
>    -- Computer Security Subsystem Interpretation of the TCSEC
>    -- Trusted Data Base Management System Interpretation of the TCSEC
>    -- Trusted Network Interpretation of the TCSEC
>    -- Trusted Network Interpretation Environments Guideline -- Guidance
>       for Applying the Trusted Network Interpretation
>    -- Trusted Unix Working Group (TRUSIX) Rationale for Selecting
>       Access Control List Features for the Unix System
>    -- Trusted Product Evaulations -- A Guide for Vendors
>    -- Computer Security Requirements -- Guidance for Applying the DoD
>       TCSEC in Specific Environments
>    -- Technical Rationale Behind CSC-STD-003-85: Computer Security
>       Requirements
>    -- Trusted Product Evaluation Questionnaire
>    -- Rating Maintenance Phase -- Program Document
>    -- Guidelines for Formal Verification Systems
>    -- A Guide to Understanding Audit in Trusted Systems
>    -- A Guide to Understanding Trusted Facility Management
>    -- A Guide to Understanding Discretionary Access Control in Trusted
>       Systems
>    -- A Guide to Understanding Configuration Management in Trusted Systems
>    -- A Guide to Understanding Design Documentation in Trusted Systems
>    -- A Guide to Understanding Trusted Distribution in Trusted Systems
>    -- A Guide to Understanding Data Remanence in Automated Information
>       Systems
>    -- Department of Defense Password Management Guideline
>    -- Glossary of Computer Security Terms
>    -- Integrity in Automated Information Systems
>
>You can get your own copy (free) of any or all of the books by
>writing or calling:
>
>    INFOSEC Awareness Office
>    National Computer Security Centre
>    9800 Savage Road
>    Fort George G. Meade, MD  20755-6000
>    Tel [phone]
>
>If you ask to be put on the mailing list, you'll get a copy of each new
>book as it comes out (typically a couple a year).

>From: [e-mail] (Karl Kleine)
>I was told that this offer is only valid for US citizens ("We only send
>this stuff to a US postal address").  Non-US people have to PAY to get
>hold of these documents.  They can be ordered from NTIS, the National
>Technical Information Service:
>    NTIS,
>    5285 Port Royal Rd,
>    Springfield VA 22151,
>    USA
>    order dept phone: [phone], fax [phone]

>From: Ulf Kieber <[e-mail]>
>just today I got my set of the Rainbow Series.
>
>There are three new books:
> -- A Guide to Understanding Trusted Recovery in Trusted Systems
> -- A Guide to Understanding Identification and Authentication in Trusted
>    Systems
> -- A Guide to Writing the Security Features User's Guide for Trusted Systems
>
>They also shipped
> -- Advisory Memorandum on Office Automation Security Guideline
>issued by NTISS.  Most of the books (except three or four) can also be
>purchased from
>
>    U.S. Government Printing Office
>    Superintendent of Documents
>    Washington, DC 20402        phone: [phone]
>
>>-- Integrity in Automated Information Systems
>THIS book was NOT shipped to me--I'm not sure if it is still in
>the distribution.

>From: [e-mail] (Jeremy Epstein)
>...
>The ITSEC (Information Technology Security Evaluation Criteria) is a
>harmonized document developed by the British, German, French, and
>Netherlands governments.  It separates functional and assurance
>requirements, and has many other differences from the TCSEC.
>
>You can get your copy (again, free/gratis) by writing:
>
>    Commission of the European Communities
>    Directorate XIII/F
>    SOG-IS Secretariat
>    Rue de la Loi 200
>    B-1049 BRUSSELS
>    Belgium

Also note that NCSC periodically publish an "Evaluated Products List"
which is the definitive statement of which products have been approved
at what TCSEC level under which TCSEC interpretations.  This is useful
for separating the output of marketdroids from the truth.

Papers:

[Morris & Thompson]
Password Security, A Case History

A wonderful paper, first published in CACM in 1974, which is now often
to found in the Unix Programmer Docs supplied with many systems.

[Curry]
Improving the Security of your Unix System.

A marvellous paper detailing the basic security considerations every
Unix systems manager should know.  Available as "security-doc.tar.Z"
from FTP sites (check an Archie database for your nearest site.)

[Klein]
Foiling the Cracker: A Survey of, and Improvements to, Password Security.

A thorough and reasoned analysis of password cracking trends, and the
reasoning behind techniques of password cracking.  Your nearest copy
should be easily found via Archie, searching for the keyword "Foiling".

[Cheswick]
The Design of a Secure Internet Gateway.

Great stuff.  It's research.att.com:/dist/Secure_Internet_Gateway.ps

[Cheswick]
An Evening With Berferd: in which a Cracker is Lured, Endured and Studied.

Funny and very readable, somewhat in the style of [Stoll] but more
condensed.  research.att.com:/dist/berferd.ps

[Bellovin89]
Security Problems in the TCP/TP Protocol Suite.

A description of security problems in many of the protocols widely used
in the Internet.  Not all of the discussed protocols are official
Internet Protocols (i.e.  blessed by the IAB), but all are widely used.
The paper originally appeared in ACM Computer Communications Review,
Vol 19, No 2, April 1989.  research.att.com:/dist/ipext.ps.Z

[Bellovin91]
Limitations of the Kerberos Authentication System

A discussion of the limitations and weaknesses of the Kerberos
Authentication System.  Specific problems and solutions are presented.
Very worthwhile reading.  Available on research.att.com via anonymous
ftp, originally appeared in ACM Computer Communications Review but the
revised version (identical to the online version, I think) appeared in
the Winter 1991 USENIX Conference Proceedings.

[Muffett]
Crack documentation.

The information which accompanies Crack contains a whimsical explanation
of password cracking techniques and the optimisation thereof, as well as
an incredibly long and silly diatribe on how to not choose a crackable
password.  A good read for anyone who needs convincing that password
cracking is _really easy_.

[Farmer]
COPS

Read the documentation provided with COPS.  Lots of hints and
philosophy.  The where, why and how behind the piece of security
software that started it all.

[CERT]
maillists/advisories/clippings

CERT maintains archives of useful bits of information that it gets from
USENET and other sources.  Also archives of all the security
"advisories" that it has posted (ie: little messages warning people that
there is a hole in their operating system, and where to get a fix)

[OpenSystemsSecurity]

A notorious (but apparently quite good) document, which has been dogged
by being in a weird postscript format.

>From: [e-mail] (Mark L. Ames)

>I've received many replies to my posting about Arlo Karila's paper,
>including the news (that I and many others have missed) that a
>manageable postscript file and text file are available via anonymous ftp
>from ajk.tele.fi (131.177.5.20) in the directory PublicDocuments.

These are all available for FTP browsing from "cert.sei.cmu.edu".

[RFC-1244]
Site Security Handbook

RFC-1244 : JP Holbrook & JK Reynolds (Eds.) "The Site Security Handbook"
covering incident handling and prevention.  July 1991; 101 pages
(Format: TXT=259129 bytes), also called "FYI 8"

[USENET]
comp.virus: for discussions of virii and other nasties, with a PC bent.
comp.unix.admin: for general administration issues
comp.unix.<platform>: for the hardware/software that YOU use.
comp.protocols.tcp-ip: good for problems with NFS, etc.

Q.20 How silly can people get?

This section (which I hope to expand) is a forum for learning by
example; if people have a chance to read about real life (preferably
silly) security incidents, it will hopefully instill in readers some of
the zen of computer security without the pain of experiencing it.

If you have an experience that you wish to share, please send it to the
editors.  It'll boost your karma no end.

---------------------------------------------------------------------------
[e-mail]: The best story I have is of a student friend of mine
(call him Bob) who spent his industrial year at a major computer
manufacturing company.  In his holidays, Bob would come back to college
and play AberMUD on my system.

Part of Bob's job at the company involved systems management, and the
company was very hot on security, so all the passwords were random
strings of letters, with no sensible order.  It was imperative that the
passwords were secure (this involved writing the random passwords down
and locking them in big, heavy duty safes).

One day, on a whim, I fed the MUD persona file passwords into Crack as a
dictionary (the passwords were stored plaintext) and then ran Crack on
our systems password file.  A few student accounts came up, but nothing
special.  I told the students concerned to change their passwords - that
was the end of it.

Being the lazy guy I am, I forgot to remove the passwords from the Crack
dictionary, and when I posted the next version to USENET, the words went
too.  It went to the comp.sources.misc moderator, came back over USENET,
and eventually wound up at Bob's company.  Round trip: ~10,000 miles.

Being a cool kinda student sysadmin dude, Bob ran the new version of
Crack when it arrived.  When it immediately churned out the root
password on his machine, he damn near fainted...

The moral of this story is: never use the same password in two different
places, and especially on untrusted systems (like MUDs).

--
 [e-mail] [e-mail] [e-mail] mcsun!uknet!aber!aem
   - send (cryptographic) comp.sources.misc material to: [e-mail] -
Xref: bloom-picayune.mit.edu alt.sources:7338 alt.sources.d:3824 news.answers:4759
Path: bloom-picayune.mit.edu!senator-bedfellow.mit.edu!athena.mit.edu!jik
From: [e-mail] (Jonathan I. Kamens)
Newsgroups: alt.sources,alt.sources.d,news.answers
Subject: Welcome to alt.sources! (biweekly posting)
Supersedes: <[e-mail]>
Followup-To: alt.sources.d
Date: 23 Dec 1992 06:01:22 GMT
Organization: Massachusetts Institute of Technology
Lines: 162
Approved: [e-mail]
Distribution: world
Expires: 20 Jan 1993 06:01:13 GMT
Message-ID: <[e-mail]>
NNTP-Posting-Host: pit-manager.mit.edu
X-Version: $Id: alt-sources-intro,v 1.6 1992/02/24 03:48:51 jik Exp jik $

Archive-name: alt-sources-intro
Submitted-by: [e-mail] (Jonathan I. Kamens)
Version: $Id: alt-sources-intro,v 1.6 1992/02/24 03:48:51 jik Exp jik $


               What is alt.sources for?

  The alt.sources newsgroup is intended to be a repository for
source-code of all sorts that people wish to distribute and share with
other people.

  There are no restrictions on the type of source code you can post
here -- any machine, any language, any purpose.

  A common reason to post to alt.sources is when you are posting a
useful bit of source code to some other newsgroup, and you think that
it might prove useful to other people in the future, in which case you
can cross-post it here.

  Alt.sources IS NOT for requests for source code; the
alt.sources.wanted newsgroup is for that.  Alt.sources IS NOT for
comments and discussion about source code, even source code posted in
alt.sources; the alt.sources.d newsgroup is for that.  Only source
code should be posted to alt.sources.

  Posting material in alt.sources that is not human readable is
discouraged.  For example, shar archives are preferred to compressed,
uuencoded tar files.  Furthermore, the posting of machine-specific
executables in alt.sources is HIGHLY discouraged.


               Why post to alt.sources?

  Since alt.sources is unmoderated, your source code will be
distributed throughout the USENET (or, at least, the portion of the
USENET that receives alt.sources) immediately, without having to wait
for a moderator's approval, like you have to do for some of the other
source newsgroups.

  Furthermore, alt.sources is archived at quite a few anonymous ftp
and mail server archive sites, so people will be able to get your
software from the archives after you've posted it, rather than having
to ask you to mail it to them.

  Finally, you might have a bit of source code that is really too
small to submit as a package to one of the other major source
newsgroups.  That's the kind of things that shows up a lot in
alt.sources.


          Why post to somewhere besides alt.sources?

  Alt.sources isn't as widely propagated as the source newsgroups in
the "comp" hierarchy, since more sites tend to get "comp" than "alt".
Therefore, if you want your source code to have as wide a distribution
as possible, you might want to use one of the "comp" newsgroups.

  The alt.sources archives tend to be less well-organized than the
archives of the other source newsgroups, because they are usually
maintained automatically rather than by hand, and because non-source
postings are often interspersed with the source postings in the
archive.  Furthermore, many of the other source newsgroups are
available at many more archive sites than alt.sources.  Therefore, if
you want people to be able to find your program really easily,
alt.sources may not be the best place to post it.


        What format should alt.sources postings have?

  Because alt.sources is unmoderated, the format your postings take is
up to you.  However, there are certain basic guidelines which, if
followed, make alt.sources a more productive newsgroup for everyone:

  1) Choose a good subject line for your posting that describes
accurately what it contains.  Many alt.sources archive sites generate
their indices of the newsgroup from the subject lines of the postings
in it, so try to make sure that there are relevant keywords in your
subject that people can search for when looking for your source code
later.

  2) Put a Followup-To: header line in your posting which directs
followups somewhere other than alt.sources.  This is especially
important if you cross-post your alt.sources posting from some other
newsgroup, because people will often respond to the posting in that
newsgroup without realizing it was cross-posted to alt.sources.

  3) At the top of your posting, separated from the main header of the
posting by a blank line, put something that looks like this:

    Archive-name: name
    Submitted-by: [e-mail]

The "name" on the first line should be a short one-word string that
can serve as a "tag" for the package.  If your program has a somewhat
unique name, you can just use the name of the program as the archive
name.  If you are posting a patch to a previously posted bit of source
code, you would do something like "name/patchN", where N is the number
of the patch.  If you post source code in multiple parts, do
"name/part1", "name/part2", etc.  The second line should contain a
return mail address for you.

  This informational header (note that it is an auxiliary header, in
the body of the posting, NOT part of the main message header) is used
by some automatic archiving software to maintain alt.sources archives
automatically.  There are other useful fields you may want to put in
the auxiliary header; if you are curious, see the documentation for
the "rkive" program in the comp.sources.misc archives to find out what
they are.

  4) Make sure to mention, near the top of your posting (or near the
top of your first posting, if you are posting a multi-posting
package), exactly what the package is.  If there is a README file,
either include that at the top or (if you are using shar) make it the
first thing in the first shar file.  People should not have to search
through the entire package just to figure out what it is.


            Where is alt.sources archived?

  See the article entitled "How to find sources (READ THIS BEFORE
POSTING)" in alt.sources.wanted and comp.sources.wanted to find out
how to search through the alt.sources archives and how to retreive
source code from the various archive sites.


          Doesn't this introductory posting
        violate the guidelines outlined above?

  Yes.  This posting is not a source-code posting, and therefore
shouldn't really appear in alt.sources.  However, the problem of
non-source postings and source postings without auxiliary headers
appearing in this newsgroup is severe enough that I hope to reduce it
by posting this message.  Other source newsgroups have similar
introductory postings, posted by their moderators.

  No, I am not the "moderator" of alt.sources.  There is none.  There
are probably people who think the guidelines I've mentioned above are
wrong.  If you think there's something wrong with this posting, please
tell me about it, either by sending me E-mail or posting a followup in
alt.sources.d.

  Although there may be specific things in this posting that people
disagree with, I think that I am, in general, outlining the consensus
of the alt.sources community.  However, if a sufficient number of
people (let's say five or more) send me E-mail and tell me that they
think I'm completely off base and shouldn't be posting this message at
all, I'll put it to some sort of vote and see what the consensus is
that way.

  Comments about, suggestions about or corrections to this posting are
welcomed.  If you would like to ask me to change this posting in some
way, the method I appreciate most is for you to actually make the
desired modifications to a copy of the posting, and then to send me
the modified posting, or a context diff between my posted version and
your modified version (if you do the latter, make sure to include in
your mail the "Version:" line from my posted version).  Submitting
changes in this way makes dealing with them easier for me and helps to
avoid misunderstandings about what you are suggesting.

--
Jonathan Kamens                                         [e-mail]
Aktis, Inc.                                 Moderator, news.answers
Xref: bloom-picayune.mit.edu comp.sys.amiga.datacomm:9660 news.answers:3865
Newsgroups: comp.sys.amiga.datacomm,news.answers
Path: bloom-picayune.mit.edu!snorkelwacker.mit.edu!news.media.mit.edu!micro-heart-of-gold.mit.edu!uw-beaver!cs.ubc.ca!destroyer!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!uunet.ca!shark!latour!mcr
From: [e-mail]
Subject: [comp.sys.amiga.datacomm]: AmigaNOS Frequently asked questions
Message-ID: <[e-mail]>
Followup-To: poster
Sender: [e-mail] (Michael Richardson)
Supersedes: <[e-mail]>
Organization: Sandelman Software Works, Debugging Department, Ottawa, ON
Date: Tue, 3 Nov 1992 14:36:57 GMT
Approved: [e-mail]
Expires: Tue, 8 Dec 1992 14:36:49 GMT
Lines: 273

Archive-Name: AmigaNOS-faq
Version: $Id: nos-faq,v 1.3 92/09/07 20:55:12 mcr Exp Locker: mcr $



        Frequently asked questions about AmigaNOS.
        ******************************************
           Michael Richardson
        [e-mail]

  I think I see at least a question about AmigaNOS every week. I'm
going to try and compile a frequently asked questions on it. I think
at least the following questions must be answered:

  1.*) general questions
  1.1) what is AmigaNOS
  1.2) what is it used for?
  1.3) how do I get it to dial?
  1.4) where can I get documentation/source/binary?
  1.5) can I do dialup X? NFS? SMTP?
  1.6) What about PPP?
  1.7) where I find out more?
  1.8) How do I install it?

  2.*) questions of a more technical nature
  2.1) Does it come with a library gives you socket calls?